2025 High Level Roadmap and recap

Greetings anon, it’s been a while.

We’re excited to share with you what we're planning to build over 2025. Yes, we know it’s already March, so let’s start with a recap of what the team has been up to in the recent months, before moving to what’s up next.

MACI Coordinator service

We are happy to announce that we completed the work on developing a service to automate MACI coordinator functionality. This includes:

• Contract deployment
• Subgraph deploying
• Proof generation
• Proof and results submission

This server exposes a REST API, as well as some Websocket endpoints (for proof generation only). We soon will publish a detailed guide on how to use, and how to integrate it via its SDK -stay tuned for a separate blog post.

For anyone interested in the code, you can find it here.

MACI Offchain voting support

After Vitalik’s post original idea, the team worked on an implementation of offchain voting for MACI. This comes in the form of a relayer service, which can be run by the coordinator to support offchain vote submission, effectively reducing the cost for users to only the signup transaction.

In the future we plan to research how to extend support to signups too.

In a nutshell, the service exposes a REST API that allows voters to submit MACI messages, they only need to prove that they are signed up by posting a zk proof to avoid spam on the service. The coordinator will wait for batches of n messages to be collected, then post the hashes of the messages to the Poll smart contract, alongside an IPFS hash where these messages are stored. This allows to keep costs down for coordinators, as they would only need to post the message hashes compared to relaying message by message and hashing them on-chain. At the same time, users can vote for free, and if they do believe they have been censored, for instance they do not see their vote on the IPFS file, they can go directly on-chain and use MACI as normal.

It should be noted that at this time, using this feature might result in failure if either of the two are true:

• The coordinator calls relayMessagesBatch with invalid message hashes (there is no corresponding message on IPFS or local relayer storage)
• The coordinator posts message hashes on chain before they are stored on IPFS and local storage is lost

While both of these result in a liveness issue, MACI does not provide liveness guarantees either way, as in its current form the coordinator could choose to not complete a poll, and no one else would be able to process votes on their behalf. We will be looking to improve on this guarantees in out future work.

MACI v3

We are very close to completing a new version of MACI - v3. This new version comes with features that have been requested in the past, such as polls being more customisable, in terms of voice credits assigned to voters, and gatekeeping mechanisms.

At a high level, the new features/improvements are:

1. Custom voice credits per poll
2. Custom gatekeeping per poll
3. Replacement of vote merkle trees for more efficient hash-chains

Up until now, MACI has not prioritised reusability of the smart contracts. More often than not, production votes using MACI relied on deploying new instances of the main MACI smart contract, resulting in users joining with a new set of keys every time. This by consequence results in these keys not holding more value than a single vote, thus enabling key selling. With this new version, we envision a single MACI smart contract to be the entry point for several polls, where voters are “forced” to signup to individual polls with the same key that they used to signup to the main smart contract. In production use cases, this could be follow this script:

1. The main MACI contract is set to gatekeep access using a very strong sybil mechanism, such as proof of passport
2. Users signup by proving they are human
3. For each poll that is created, voters can join with the same key if they wish to participate and if they can pass the specific poll gatekeeping requirements. For instance a specific poll might allow only Indian voters, thus use a Anon Adhaar gatekeeper to gate access

User research

In order to inform MACI’s future roadmap and which use cases to tackle, we started to conduct user research. MACI has been historically used only in public goods funding, via protocols such as clr.fund, QFI, Gitcoin’s Allo stack, and MACI Platform. As we see a diminished interest and need for private voting in public goods funding, we decided to focus on a new use case which clearly has a larger demand for MACI - governance.

While still in the early discovery phase, we identified demand for MACI to be integrated into DAO governance protocol stacks like Aragon’s OSX in the form of a plugin. We are aiming to build a demo plugin and showcase it to Aragon in the coming months.

We hope to partner with several governance providers to enhance your voting offerings through modules/plugins.

2025 - What will we focus the rest of the year

For this year, we plan to tackle a few different epics:

1. Release of MACI v3
2. Begin work to decentralize the coordinator using either homomorphic encryption or collaborative SNARKs
3. Integrate MACI into Aragon OSX’s stack
4. Continue with user research

MACI v3

We have just talked about MACI v3, so what is left to add is that we will be looking to complete the documentation updates, clean up the code and release it as soon as possible. Get ready for an even better version of MACI, and please reach out if you would like to integrate v3, we are here to support.

What about coordinator decentralisation?

That sounds interesting.. Let’s talk about that.

One of MACI long standing issues has been the privileges that the coordinator role has. They are able to see all of the votes in cleartext, which allows them to collude with bribers themselves, as well as voters. As we look to tackle use cases such as DAO governance where lot of money is involved in proposals, we need to ensure that collusion between the coordinator and voters/bribers is reduced. This can be accomplished in several ways:

• Use Multi Party Computation (MPC)
• Use Homomorphic Encryption (HE)
• Use a Trusted Execution Environment (TEE)

Without going into much details here (keep an eye out for a separate post), to actually decentralise the coordinator role we will need either MPC (in the forms of co-SNARKs) or HE. The team is researching the available technologies to come up with a proposal on how to tackle this problem. We are very excited to improve MACI’s security and bring an even better primitive to projects that want private and secure voting.

Integrating MACI into the Aragon OSX stack

After some discussion with Aragon, we decided to build a demo to showcase how MACI could be used in DAOs created using Aragon’s OSX stack.

The goal is to get a working demo in the coming months that allow to create new voting proposals where DAO token holders can vote Yes, No, or Abstain. At this time, we will be making a very simple integration, and in the future we plan to integrate some features into the MACI protocol which would make it more suited for DAO governance, such as:

• Have a custom type of polls where one can only vote with all of their voting power (currently there is no option to restrict this and voters can allocate their voting power as they prefer across several available options)
• Count the number of votes for each option (currently this is not possible, the coordinator would need to provide this information, without a way to prove its correctness)

Once the demo is out and some DAOs test it out, we look forward to preparing this to be production ready and target running some DAO voting, from a supportive perspective.

You can track progress of development on this repo.

Continue with user research

While we have identified a new use case to tackle, governance, we still want to continue speaking with different projects and individuals to learn even more where can provide value in the short, and long term.

We have identified some projects that we want to chat with, however are open to suggestion - know anyone that is interested in private and anti collusion voting? Introduce them to us to help us understand how we can help democracy thrive.